Maintenant que nous avons signé notre application, nous pouvons passer à la mise en œuvre des mises à jour de l'application.
C'est, bien sûr, une fonctionnalité extrêmement importante car elle nous permet de corriger des bugs ou d'apporter des améliorations à
notre application et d'avoir automatiquement la mise à jour de l'abuseur existant vers cette version plus récente.
En gros, cela peut se produire de deux manières, selon la manière dont l'utilisateur final a installé votre application.
La première option est que vous avez publié votre application dans un magasin d'applications comme le Mac App Store, auquel cas
le système d'exploitation prend en charge les mises à jour.
Lorsque vous avez une nouvelle version, il vous suffit de la publier sur l'App Store et les utilisateurs sont informés et mis
à jour.
Donc hors de nos mains et rien à voir avec l'application elle-même.
La seconde est que vous avez distribué votre application directement à l'utilisateur final, et non via une boutique
d'applications officielle.
Dans ce cas, nous avons besoin d'une fonctionnalité intégrée pour vérifier les mises à jour chaque fois que l'utilisateur
lance l'application et installer la dernière s'il y en a disponible pour ce faire.
Electron nous fournit un module intégré appelé Auto Updater, mais nous n'utiliserons pas celui-ci.
Au lieu de cela, vous utiliserez le module de mise à jour automatique bien supérieur d'Electron Boulder.
La principale différence est que le programme de mise à jour des électrons nécessite un serveur de mise à jour dédié, un
élément supplémentaire de complexité et de maintenance dont nous pouvons vraiment nous passer à la place.
Ensuite, Electron Balde permet d'héberger les mises à jour sur GitHub.
Ben, essayez Amazon S3 ou même Digital Oceans Spaces examinera GitHub ou plus précisément les versions de
GitHub.
Les versions sur GitHub font partie de n'importe quel référentiel de code standard et sont gratuites, par exemple, sur le référentiel de code de projet, que je
vais utiliser comme serveur de publication pour l'application Read It.
Nous pouvons à nouveau trouver des communiqués ici.
Chaque dépôt a ses propres versions.
La façon dont Electron Balde détermine le référentiel à vérifier pour les versions est ensuite par le champ de référentiel
dans le package de projet ou le fichier JSON cette année.
Assurez-vous donc que cela est défini pour vos applications.
Repo GitHub.
J'ai déjà l'ensemble pour le repo.
Je vais utiliser.
Notez également qu'électron builder prend en charge les dépôts publics et privés et que vous n'avez pas nécessairement à
engager votre OPKO dans le dépôt pour pouvoir l'utiliser pour les versions.
J'ai évidemment le code du projet dans ce référentiel, mais devriez-vous souhaiter utiliser un référentiel public gratuit comme
celui-ci sans valider votre code up?
Créez-en un et validez un simple fichier README.
Le code de l'application n'est pas nécessaire.
OK, le navigateur libère.
Je n'en ai pas, alors allez-y et créez une nouvelle version.
Nous devrons d'abord définir les informations de publication en tant que version de la balise, car chaque fois
que vous créez une version, GitHub créera également une balise pour cette version ou plutôt pour le dépôt à
ce moment-là.
La dénomination de cette version de balise est cependant très importante.
Cela doit correspondre à la version finale de votre application définie dans le fichier Dodgson du package lors
de sa construction, qui dans le cas de cette version écrira comme V pour la version un point zéro point zéro.
Je suggérerais également de s'en tenir au versionnage sémantique de la version majeure étant le premier numéro, la version mineure,
la deuxième et toute version de correctif ou bogue corrige le troisième numéro.
J'ai lié à une explication du versionnage sémantique dans les ressources réduites.
Si vous ne le connaissez pas, nous pouvons donner à cette version un titre significatif.
Je vais dire première version.
Et un journal des modifications dans la description publiée, le format n'a pas vraiment d'importance, mais un point
à puce est de bonnes corrections de bogue et ajoute la fonctionnalité X.
C'est tout ce dont nous avons besoin pour le moment.
Nous ne téléchargerons pas les versions nous-mêmes.
Electron Boulder s'en chargera pour nous.
Tout ce que nous faisons ici est de donner à Electron Boulder un projet de version pour mettre à jour également le nouveau projet de loi.
Alors enregistrez-le comme brouillon ici.
Ceci est maintenant prêt, non publié, mais prêt pour qu'Electron Boulder télécharge également une nouvelle facture de sortie.
Avant de pouvoir faire cela, cependant, nous devrons donner à Electron Boulder l'accès à ce repo afin
de télécharger le Newbold.
Pour ce faire, nous devrons créer un être personnel de jeton d'accès personnel unique.
La clé ici, cela va essentiellement fournir le même accès que vous avez.
Ce n'est pas spécifique au dépôt, alors pour ce faire, accédez à vos paramètres.
Ouais.
Paramètres du développeur sur la gauche.
Jetons d'accès personnels.
Générez un nouveau jeton, qui vous demandera votre mot de passe à confirmer.
Donnez à ce jeton un nom mémorable, je l'appellerai reedit releases.
Ensuite, par défaut, ce jeton n'a accès à rien, nous devons donc indiquer à Giddyap quelles sont les étendues
d'accès à Grant, le porteur de ce jeton pour que le constructeur d'électrons télécharge des versions, il n'a besoin que d'un
accès au repo ici.
Ce premier avec toutes les sous-étendues associées génère un jeton.
Et il y a ce jeton n'apparaîtra qu'une seule fois, donc dès que cette page sera fermée ou rechargée, vous ne
pourrez plus voir le jeton.
Alors copiez-le.
Et où je vais enregistrer le mien, c'est dans ce même répertoire privé que j'ai les fichiers cert, donc dans le répertoire
du projet.
À droite, le jeton dans un simple fichier texte avec un écho du jeton sous forme de chaîne, donc en le
mettant entre guillemets dans le G. H. le texte du point de soulignement du jeton, le trait de soulignement Tolkan étant la variable d'environnement
à laquelle attribuer ce jeton lors de la construction d'une nouvelle version.
Cette façon de stocker le jeton n'est en aucun cas une exigence.
Stockez simplement le jeton dans un endroit sûr où vous pourrez facilement y accéder lors de la création de votre application.
OK, nous avons maintenant rédigé notre première version et un jeton d'accès pour GitHub.
Nous pouvons configurer Electron Balde pour utiliser GitHub comme serveur de publication pour le relire sur le guide de mise à jour
automatique.
Nous pouvons trouver la documentation pour ce faire ici.
Publier la configuration étant cette dernière section ici et les documents.
La première chose à noter ici est que lorsque nous définissons une variable d'environnement de jeton souligné lors
de la construction de notre projet, le fournisseur sera automatiquement GitHub, ce que nous allons faire.
D'où la raison pour laquelle nous enregistrons ce jeton GetUp dans un fichier de ce nom.
Ensuite, la chose suivante consiste à définir la clé de publication.
Cela peut contenir un certain nombre de fournisseurs dans une réforme, mais ce n'est généralement pas nécessaire.
Vous pouvez également définir cette clé sur une base spécifique à la plate-forme, afin de potentiellement publier différentes versions de
votre application à différents fournisseurs.
Encore une fois, ce n'est pas un scénario courant dans notre cas.
Ensuite, nous pouvons simplement définir une clé de publication commune sur l'électron, une configuration sur l'ojisan emballé.
Je vais d'abord me débarrasser des cibles Mac.
Laisser les cibles par défaut est ce que nous voulons pour une distribution indépendante.
Et sur cet objet de construction, créez une clé de publication.
Le fournisseur public mondial étant GitHub, s'appliquant donc à tous nos Bolds, Mac, Windows et Linux, c'est essentiellement tout pour configurer
les versions de GitHub en tant que serveur de mises à jour.
Ensuite, nous pouvons ajouter un nouveau script d'exécution pour publier également un nouveau bloc dans le jeu d'objets scripts, une nouvelle
commande appelée Release.
Sur lequel je vais exécuter le générateur d'électrons.
Gras ou laissez-le simplement de côté pour Mac, Windows et Linux, car une nouvelle version sera probablement applicable à toutes
les plates-formes.
Je vais juste le faire Mac uniquement à des fins de démonstration, cependant, et surtout, dire à
Electron Builder dans quelles conditions publier cette nouvelle version.
Nous mettons cela sur le drapeau public ou P en sténographie.
Et comme cet indicateur nécessite une valeur, nous avons quatre options sur la boîte publiée.
Oui, ce sont les quatre valeurs possibles que nous pouvons transmettre à Electron Baldor sur ce drapeau public
untag, c'est-à-dire si une balise pour cette version de l'application existe dans le repo sur la balise ou le brouillon.
Donc comme le premier, mais aussi si un brouillon existe, ce que nous avons toujours, comme son nom l'indique, créer le communiqué
à chaque fois pour les audacieux.
Et enfin, jamais une option redondante, comme mentionné, ne voudra l'utiliser sur une option d'étiquette ou de brouillon.
Alors copiez ça.
Et si cela est un peu déroutant, tout cela signifie que si le serveur de version spécifié
GitHub, dans notre cas, contient une balise ou un brouillon pour la version en cours de construction, téléchargez cette facture, publiez une version
et une balise est essentiellement le même chose.
Lorsque vous créez une version sur GitHub, votre dépôt est marqué à ce stade.
La principale différence en autorisant une balise ou un brouillon est que nous pouvons publier la version manuellement
après son téléchargement.
Cela évite d'avoir une version publiée sans aucun Boult téléchargé dessus.
En d'autres termes, ce à quoi nous nous attendons maintenant, c'est que lorsque nous construirons notre projet, Electron
Baldor vérifiera une version, une version ou une balise correspondante sur GitHub.
Celui-ci télécharge ici la cible de construction dans cette version.
Comme vous pouvez le voir, cela peut également être fait manuellement ici.
Et après cela, quand nous sommes prêts, nous pouvons simplement aller frapper, publier, libérer.
Nous pouvons ajouter cette valeur de publication copiée à partir des documents entre guillemets, décocher ou brouillon.
C'est notre commande de publier ou de publier un nouveau bloc.
Nous pouvons tester cette version encore en construction.
C'est la version pour laquelle nous avons créé notre version sur GitHub pour le terminal appelant NPM Run release ce
nouveau script d'exécution.
Mais pour permettre à Electron Builder de télécharger notre Newble sur GitHub, nous devons également fournir notre
jeton d'accès GitHub.
Celui-ci ici, sûr de souligner le jeton.
Et si vous vous souvenez, la raison pour laquelle je l'ai enregistré sous ce nom de fichier est que G. H. Underscore Tolkan est le nom de
la variable d'environnement que nous devons définir avec cette valeur de jeton pour faire cela avant cette commande de
version.
G. H. le jeton de soulignement est égal à cette valeur de jeton sous forme de chaîne.
Là, si vous êtes sous Windows, l'équivalent de ceci sera défini X G. H. souligner Tolkan avec la valeur du
jeton.
Donc, de cette façon, nous ne définissons le jeton que lors de l'exécution d'une version,
mais le gardons essentiellement en sécurité, OK, exécutez ceci, ce qui exécute le Makled comme nous l'avons vu précédemment.
Mais cette fois, dès que le boulon est fait, je vais passer à ça.
Nous obtenons cette étape de publication sur GitHub, la version principale du repo d'électrons, un point zéro point zéro, à quel point
le constructeur d'électrons commencera à télécharger les Newbold dans cette version préliminaire qui correspond à la version
de ce boulon.
Ces sorties peuvent parfois être un peu incohérentes et des artefacts grossiers comme celui-ci, mais ce n'est que
la sortie.
Comme vous pouvez le voir, cette ligne se poursuit ici maintenant.
Je vais sauter à nouveau et j'ai fait toute notre nouvelle version, une, make cibles a maintenant été téléchargée dans
le brouillon publié sur GitHub.
Vérifiez cela de nouveau aux versions.
Là où nous avons maintenant quatre actifs, cliquez pour les développer.
Et ils l'ont lu la version un, zip, un DMG et deux fichiers auxiliaires utilisés par le programme de mise à jour automatique lors de la
vérification d'une nouvelle mise à jour, ce dernier Mac d'un an étant le plus important.
Inspectez ce fichier dans le projet.
Dernier Mac Dot Yamal, qui contient toutes les informations de mise à jour automatique de l'électron Boulder.
Un module doit télécharger et vérifier l'une de ces cibles publiées par Mac à partir de GitHub.
Et bien sûr, comme nous pouvons le voir ici, nous avons toujours la nouvelle construction dans le répertoire comme avant.
Aucun changement là-bas.
OK, ça a marché.
Mais pour le moment, cette version est encore une ébauche, ce que nous voulions.
Nous sommes maintenant sûrs que tout a fonctionné et que l'application Target a été téléchargée avec succès afin que nous puissions
publier cette version, modifier le brouillon.
Et tout en bas, publiez, libérez.
Et c'est fait, cette version est maintenant disponible et peut être utilisée par les constructeurs d'électrons, le programme de mise à jour automatique
pour mettre à jour une application avec une version inférieure à un point zéro point zéro.
Nous n'avons, bien sûr, pas encore implémenté la mise à jour automatique.
Donc, dans la prochaine leçon, nous le ferons et verrons comment cette mise à jour est trouvée et utilisée.